Business Analyst Community & Resources | Modern Analyst

Every Business Analyst Must Negotiate Like a Pro

Adrian M. — Wed, 11 Feb 2015 00:45:00 GMT

In the larger context of life, it is very clear that negotiation skills are very important and that those that have them are better off than those who don’t.

What about in business analysis? Are negotiation skills important?

The answer is an emphatic: YES! You bet they are!

Business analysts negotiate or facilitate negotiations at every turn. At the very infancy of a project, negotiation skills are used to determine what should be included in the vision of the project, in the project charter.

As details emerge, negotiation skills are used by all parties involved to determine which requests become requirements and which requirements have higher priority.

As the project progresses, negotiation skills are again used to determine the functional design which fulfill the requirements. Technical decisions also require negotiation skills.

While it would be much easier if project decisions were black and white (objective) the reality is that everything is negotiable.

So – if you are a business analyst or systems analyst make sure to add negotiation skills to your repertoire.

Certain individuals are great negotiators from birth, the rest 95% of us need to work on these skills.

We can’t afford not to!

By now you might be wondering if you can do it – if you can be an effective negotiator!

Yes! You can negotiate anything!

Here are some tips and guidelines to help you get started. These are really the notes I jotted down while reading “You Can Negotiate Anything!” a great book by Herb Cohen.

Definitions

Negotiation = activity in which parties are trying to satisfy needs.

Process of Negotiation = It is a way of acting and behaving that can develop understanding, belief, acceptance, respect and trust. It is the manner of your approach, the tone of your voice, the attitude you convey, the methods your use, and the concern you exhibit for the other side’s feelings and needs.

Negotiation Myths

MYTH # 1: We want the same thing therefore if you win I lose
The majority of us think of negotiation as a pie that needs to be divided. Therefore if you get the bigger piece then I get the smaller piece. If I win then you lose. The reality is that needs are not always in opposition: In most negotiating situations, the needs of the two parties are not really in opposition. In a collaborative Win-Win negotiation we are trying to produce an outcome that provides acceptable gain to all parties.

MYTH # 2: Money is the most important thing to the other party
While money is not everything in life, it surely nice to have lots! Deep down each one of us think of negotiation in terms of money. Money seems to be an easy and objective way to keep score and to decide if I negotiated a good deal or not.

The reality is that money is not the only need. If you think most negotiations pivot around money, then you’re mistaken. Money is a need but is only one of many. If you neglect their other needs, satisfying people’s dollar need alone will not make them happy.

MYTH # 3: The other party told me what they want
Most of us assume that the other party will or have already clearly communicated to us their needs and wants. The reality is that the real needs of the other party are often not considered for a number of reasons. Negotiations are never totally about what is being openly talked or contested, be it price, services, products, territory, concessions, money, etc – because negotiators try to conceal real needs or don’t recognize them.

Many folks use negotiations as way of satisfying deeper, often subconscious, needs such the need to be appreciated, wanted, and recognized. What is being discussed, and the manner in which it is being considered, are used to satisfy psychological needs.

Win-Win Negotiations

PRINCIPLE: Negotiate for Mutual Satisfaction (Win-Win)
If there is only one thing that you get out of this article is the importance of having a win-win view of the negotiation process. Successful negotiators view the opposing party as colleague rather then an opponent.

The goal at the end of the day is for the parties to shake hands and say something like “That was fun and mutually benefiting! Hope we get to do this again sometime!”

Therefore, your goal and mindset in any negotiation should be to:

Use the process to meet needs (the other party’s needs)
Harmonize or reconcile needs (yours with the other party’s)
Watch for and avoid conflicts which stem from differences in experience, information, and role.

More tips to achieve win-win outcomes for the business analyst:

Build Trust - Find out as much as you can about the other party needs and wants, show genuine concern for the other party’s welfare, and transform the relationship in to collaboration.
Don’t make enemies – As a business analyst you interact with people possessing various levels of knowledge. If you know more or understand it better don’t forget the power of your attitude – check your own ego at the door.
Communicate your needs – Many of us do not succeed at negotiations because we don’t make our needs known. The squeaky wheel really gets the grease, if it knows where, when and how to squeak.

The bottom line is that as a business analyst or systems analyst, you can’t afford not to learn how to negotiate. Learning to be a good negotiator takes time so start now.

If you don’t plan on making a conscience effort to improve your negotiation skills through practice, reading, courses, etc., then keep this on thing in mind… try to help the other person win, make them successful, they’ll remember you.

Another way to put this is summarized by the golden rule: “treat others as you would like to be treated.”

If you do this you’re well on your way to many successful negotiations.

Adrian

From Developer in India to Business Analyst Abroad

Adrian M. — Wed, 28 Jan 2015 12:19:00 GMT

Business Systems Analyst as a Career Option

If you are an IT professional in India, thinking of working abroad, you might want to consider a business/systems analyst position.

Why?

It’s a position in high demand with high earning potential and which can serve as a great foundation for moving up the corporate ladder into management or business operations.

In on of Money Magazine’s Best Jobs in America list, the Computer/IT Analyst career was ranked 7th, out of 50 best jobs, with a 10-year job growth of 36.10%.

In one of their “Best Careers” report, US News and World Report lists 25 professions that will continue to grow in demand. With the advent of outsourcing, it is not surprising that the software engineer or web developer professions are NOT on the list - however systems analyst is.

All industrialized nations are heavily outsourcing the programming of software to other parts of the globe such as Russia, India, China, Eastern Europe, and South America.

While there’s still demand for developers, of course, the information economy has created an ever increasing need for business analysts and systems analysts.

As a matter of fact, the very outsourcing of programming jobs has caused a spike in the demand for business systems analysts. The increase distance between the business stakeholder and the programmer has created an increasing need for higher quality and more precise analysis artifacts such as requirement documents and functional specifications.

In addition – in a more an more competitive economic landscape business organizations continue to strive to improve their business processes and reduce costs. Business analysts are at the center of most of these initiatives.

So are you ready to make the move?

Before you take the plunge, you should do a quick self assessment to determine if the business analyst role might be a good fit. You’re probably a good candidate if:

you don’t want to spend the rest of your career in front of a monitor debugging code,
you love to talk to people and socialize,
you not only love to talk to people but you are actually a good communicator,
you are good at organizing information in a structured and concise manner for others to consume,
you want to, and are able to, grasp the big picture,
you are fascinated by how companies actually make money, about the business systems and processes in place.

OK… so if you still think that business systems analysis is for you, then let’s take a quick look at what you need to begin a career as a business/systems analyst.

For starters, if you are a developer you already have a great advantage:

you think in a structured manner,
technology is not magic but something you actually understand,
you are most likely used to working in a variety of industries,
lack of detailed business knowledge causes you to ask very relevant “why” questions,
you know how to talk to the technical side, and
you probably have already been reviewing artifacts created by the business analysts.

So what’s next?

If I were forced to pick the top two skills or abilities that a BSA must have I will always pick strong communication skills and analytical (structured) thinking.

Communication Skills

The first thing you need to focus on is communication skills. No matter how good your communication skills are you can always learn more. This is a must have skill for the business systems analyst.

If you are assessing your abilities and trying to figure out which aspect of communication to work on next, here are some areas to consider (pick the one in which you are the weakest and run with it):

ability to verbally communicate your thoughts and ideas to others and make yourself understood,
ability to understand others and to ask relevant questions which cause the other party to give you the information you are looking for,
ability to write clearly and in a concise manner (when creating analysis artifacts - less is more)

Analytical/Structured Thinking Skills

The next thing is structured (logical) thinking… this is one of those aptitudes which, at some level, I almost want to categorize as “you either have it or you don’t.” However I haven’t yet found conclusive evidence to support my claims – not yet.

So for now, work on improving your analytical and problem solving skills as without them, you will fail as a business systems analyst or, at best, you will be a technical writer with a BA title.

If you are assessing your skills in this area you might want to consider focusing on the following:

techniques which help you organize your thoughts or the facts about a given problem,
methods of making a problem more manageable such as: divide and conquer, abstraction, problem solving patterns,
formal reasoning skills such as: propositional reasoning, identifying and controlling variables, suppositional reasoning, etc.

For more details check out Mind Tools, a good resources of ideas and techniques to improve your analytical and structured thinking skills.

Keep on Learning

While I would argue that a software developer/programmer with strong communication skills and great analytical/structured thinking can easily land a business/systems analyst job, there numerous other abilities and skills you should develop if you plan to make business analysis a long-term career.

Here are some things to think about:

Requirement Elicitation Methods – as a business analyst you will be eliciting requirements from the business stakeholders therefore it will serve you well to become familiar with various requirement gathering techniques such as: end-user interviews, job shadowing, questionnaires, etc.
Vertical domain knowledge – if you are interested in a given industry (ex: mortgage banking, pharmaceutical, etc.) or if you already have previous experience in a given industry you should consider beginning your business analyst career in that industry. Of course – learn as much as you can as the more you know about a given business domain the more effective you will be as an analyst.
Knowledge popular modeling techniques (activity diagram, sequence diagram, data flow diagram, workflow/process flow diagram, etc.)

Adrian

The Case for System Documentation aka "Developer Is No Longer King"

Adrian M. — Wed, 14 Jan 2015 23:01:00 GMT

If you are managing a team of business analysts or systems analyst you probably have two main goals in mind:
- to make sure your team understand the requirements (the real ones)
- to make sure that you develop a solution which makes sense in the context of your constraints.

The chances are that one of your biggest constraints is a current system. Few of us have the luxury of working on developing brand new systems starting with a clean slate.

Most of us need to be able satisfy the new requirements in the context of an existing system. But do you know what the current system does?

Do you know the “AS-IS” of your system?

At the core of the Agile manifesto is the call to value “working software over comprehensive documentation”.

I could not agree more!

After all – what good to anybody is the documentation if the software doesn’t work?

Unfortunately many proponents of Agile development tend to miss the fact that the agile manifesto does not say “no documentation”. Whether this is by mistake or by design, I don’t know.

But I do know that, as a business analyst or system analyst, decent documentation made my life much easier and saved my clients a ton of money.

Let’s assume for a second, that the software does work… and that whoever specified and implement the first version did such a great job that the software satisfies all the initial requirements.

But also assume that there’s not documentation!

Now you are hired as the next business systems analyst and are being tasked to help out with the development of version 2 of the software. You might be able to do a great job gathering the requirements but when it comes to specifying what needs to change about the system – you’re stuck! You don’t know what the system does… Yes – you can play with the current system and try to infer what it does but unfortunately the only documentation is “the code”.

Let’s be honest – the technical landscape is constantly changing and most business analysts (even the technical ones) do not have the time or the inclination to maintain enough development skills so that they would be able to navigate their way through a number of technical layers (databases & stored procedures, middle layers and services, web server code and client side-script, etc.) a variety of languages (SQL, C#, JavaScript, Java, etc.), as well as a mixture of architectural models (Client-server, SOA, n-tier, etc.)

You are now at the mercy of the developers – and hope that some of the ones which developed the first version are still around.

These types of environments are the ones where the developer is King. The analyst finds himself at the mercy of those who can read code and navigate the technical layers.

I am not advocating that, as a business analyst or system analyst, you do not increase your technical skills; I’m just saying that, unless you become a developer, you’ll need some level of system documentation to point you in the right direction.

As a rule of thumb here are a few project characteristics which would indicate that maintaining live system documenting might be advisable:

the project is large (with a large team)

the business domain is very complex

analysis is done on-shore but the development is done off-shore

the system is supposed to be in use for years to come (i.e. there will likely be lots of turnover in staff over the years)

regulatory requirements exist which require certain level of system documentation (at least in the area of security, legal compliance, etc.)

building services or components which will be re-used by other teams (the clients)

I will be the first to admit that maintaining decent (good enough) system documentation is not easy. In large teams and large projects you must have the commitment of the management (the folks with the money) to maintain system specifications.

I have worked on many a project where the initial set of documentation was quite good but as soon as the first “emergency” arose, exception was granted to code without specs which were supposed to be updated “later”. In such cases – “later” usually never comes.

Another must for your organization, if you’re going to maintain system specs, is guidelines and standards. Whatever level you decide to maintain your specs you must create and publish a set of standards for your documentation. This way everybody knows how to read it and how to keep it in synch with the code.

Do you maintain system documentation? Why or why not?

Adrian

You Must Question Requests from the Business

Adrian M. — Wed, 07 Jan 2015 12:52:00 GMT

A while back, I was reading a Computerworld - Singapore article on Business Intelligence and embedded in it was a small, but significant, truth about the business analyst role.

The article points out that a common mistake made by many organizations is to treat the business analyst as a request taker. That is - if the business division asks for a change in the process (or requirements, for that matter) the business analyst is supposed to just do it. In other words, they expect the business analyst to be a "yes man" (or woman).

Many folks tend to forget that the word "analyst" is actually part of the titles of the "Business Analyst" and "Systems Analyst" roles. One of they key responsibilities of the business analyst is to analyze the information received and question that information if it does not make sense.

There can be nothing worse than an organization paying top dollar for qualified business and systems analyst only to treat them as note takers or technical writers.

One of the key values that a business analyst brings to the table is the ability to innovate... the ability to ask "Why?"

The other day - I was reviewing a new set of requirements from the business side and noticed one of them which did not make any business sense.

So I dared to question it...

When I question requests from the business I tend to use a very simple approach:

Why?
Why?
Why?

In this particular case, the answer I got was "Because Mr. X said so!"

What? Because one person said so, it doesn't make it so!

Along with every new requirement and change in business process there must be a justification and clear rationale for the request. If it is not clear that the effort will improve the bottom line - then question it, question it, question it!

As a business analyst you need to make sure that somebody (it doesn’t always have to be you) has analyzed the situation and determined that a change in process or system is needed for one of the following reasons:

it reduced operating costs,
it increases productivity (makes money),
it meets regulatory requirements.

I realize that there are other, more subjective, reasons to make modifications such as increased usability of a product, look and feel requirements, etc. Those types of reasons need to be treated with caution because it is hard to objectively quantify their impact to the bottom line.

What are my motives?

... if you question requirements: What are your motives?

After years and years in this profession - this is something I do without even thinking about it - a matter of habit. But after a little bit of introspection here are some of the reasons why I question business requests:

From a pure business perspective, I want to make sure that the change in process or system improves the bottom line. From a sense of preservation I want the organization I work for to be in business for a long, long time.

Because they hired me to do so... I am being paid for my ability to think and solve problems not for my request taking skills. If that was my goal - I would have become a waiter (no disrespect for waiters intended).

Because deep down in my gut I can't stand designing or asking the developers to implement a change in the system which does not make business sense. Such features are bound to be changed again in the future and are a waist of everybody’s money, time, and effort.

Please note that I am not advocating that you overtly question every single request from the business. If you do that, you'll find your way out the door very quickly.

But you should analyze in your mind every requirement to make sure it makes business sense (at least from your perspective).

Use your better judgment and focus on the requirements with the biggest problems.

If you manage and lead business analysts then you must ensure that you get commitment from upper management on the role, responsibility, and authority your analysts must have. Then turn around and empower your team. Make sure they understand that they are allowed to and must question those business requirements (with tact - of course) which are suspect.

Do you question requirements? When? How?

Adrian

Employers Should Do More to Train Business Analysts

Adrian M. — Wed, 17 Dec 2014 12:45:00 GMT

While the Business Systems Analysis line of work is just beginning to be recognized as a profession of its own, the shortage of business analysts and systems analysts continues to get worse.

And the shortage is global!

Would you believe that India is having a shortage of qualified IT professionals? Well, you better believe it!

A while back, Mary Hayes posted a great piece on the shortage of IT talent in India. She stated that “the IT talent shortage there has hit a tipping point.” Four companies alone, Accenture, IBM, Infosys, and Tata were looking to hire additional 35,000 tech workers in India in just the first 6 months.

A separate article, discussing the business analyst shortage in Australia, states that there are simply not enough people to fill the open business analyst positions.

In the USA, the shortage of qualified analysts is just as bad. Just take a look at the sheer number of job postings for business analysts and systems analysts on the major job boards (Dice.com, Monster.com, etc.).

Should universities crank out more graduates?

The reality is that universities can only teach so many technical skills. And most of them do not teach critical competencies need by analysts such as big picture systems thinking, soft skills, problem solving, and requirements elicitation.

I graduated with a degree in Computer Science from UCLA, a school well known for its engineering degrees. However, I had only one course which taught me skills which I had later used as systems analyst. And that course was taught by an outsider, a consultant from RAND corporation. He split the class into small teams and told us to come up with a software product, pitch the idea in front of the entire class, document the requirements, design the system, build it and try to sell it.

Wow! That was cool!

Unfortunately, that was the only such course that UCLA offered and it was just a pilot course which was available for only two quarters (I hope they brought it back).

Most college professors do not have industry experience – they have rarely been involved in developing real systems that customers pay money for.

I am not saying that a technical degree is of no value – I’m just saying that it’s not enough.

So what is the answer?

I believe that employers should do more – much more - to address this problem. Large companies should create in-house training programs to teach real-world skills to future business and systems analysts through a variety of methods: seminars, mentoring, real-life projects, etc.

Many recent tech graduates would be willing to commit to a 2-3 year stay with a major company if they are promised a well-thought out training plan and the prospect that at the end of the training period they would have gained the competencies needed to succeed in the real world as professional business analysts or systems analysts.

Some companies are getting the message!

Infosys, started a program called Campus Connect to polish up the basics and teach vital skills to engineering/computer science students in colleges across India. Yes, they have a great incentive: about 24,000 tech job openings per year.

Kudos to Infosys!!! Everybody benefits!

The Campus Connect program teaches students critical skills such as:
- Systems analysis
- Hardware architecture
- Data storage
- Soft skills
- Problem solving,
- Etc.

Do you think the employers should do more to reverse the shortage trend?

Would love to hear your thoughts!

Adrian

The Popcorn Way and the Business Analyst

Adrian M. — Wed, 03 Dec 2014 12:20:00 GMT

The problem: Do you know when you’re done?

Given a specific project with a reasonably defined charter and clear business goals you, the business analyst, set out to elicit and document the detailed business requirements.

So when do you stop?

Whether you lead a team of business analysts or you do the work yourself, you probably struggled trying to determine when you should be done gathering the requirements?

If you are a perfectionist, or know one, you’ll realize that it is possible to spend unlimited time trying to discover new requirements or to refine existing ones. However, in real life and real projects the customer cannot (and will not) spend unlimited amounts of money to build a system.

At some point you have to draw a line in the sand and say “We’re done… at least for now!” The crux of the matter is to determine when we’re done.

One of the most often quoted heuristics offered to answer this question is the 80/20 rule (or better yet the 20/80 rule). That is, spend the 20% of effort which uncovers 80 % of the requirements.

That’s easier said than done!

How do you know that 20% has gone by or that you have uncovered 80 % of the requirements?

To tell you the truth – I have no clue!

The Solution: The Popcorn Way

With the charter and goals of the project in mind, I estimate (or guesstimate) upfront how long I think the requirements gathering activities should last….

… and then I use The Popcorn Way.

I found the technique on the back of my microwavable popcorn bag.

I goes like this:

Microwave popcorn on high for 2.5 minutes (on 500 Watt microwaves) *
Listen for the distance between pops
When the distance between pops exceeds 2 seconds, turn off microwave.

* Note: the actual popping time may vary.

By now you’re probably thinking that I’m going crazy… and maybe I am… but that’s a topic for another time.

If you translate from Popcornish to English, it goes like this (see basic language lesson in appendix):

Elicit, document, and analyze requirements for {estimated duration} using {available resources}
Pay attention to the information that you’re getting and determine the duration between discovering new requirements or significant changes to existing requirements.
If distance between requirements is less than {the threshold for your situation and project}, then end the requirements gathering activities.

* Note: the actual total duration may vary due the type of project and the characteristics of the analysis team.

The basic thought is that during the requirements elicitation process it comes the time when you, the business analyst, realize that you’re finding less and less requirements even though you may be getting more and more information.

When you come to that realization – it’s time to stop – at least for now.

Putting in into Practice

Once you have mastered The Popcorn Way your gut will guide you.

You will be able to clearly spot the requirements silence.

You may be only part way during your estimated duration yet you’re not getting any new requirements or significant changes to existing requirements.

Stop! You’ve probably over-estimated.

Or, you may find yourself scrambling for the pen and paper (or typing 100 words per minute) trying to capture all the requirements flying at you… In this case, you’re definitely not yet done. Should you find yourself in this predicament after your estimated duration elapsed, you've most likely under-estimated the effort.

The Dangers of not following The Way (the Popcorn Way, that is)

I’ll keep this very simple:

If you stop too early you’ll have un-popped kernels => you've missed critical requirements and, from business analysis perspective, you failed.
If you wait too long you’ll burn the popcorn => you've wasted valuable time and probably made real requirements indistinguishable from the fluff. Again – this is not a desired outcome for a business analyst.

Do you use the popcorn method? Do you know when you’re done?

I would love to hear from you! Happy Popping!

The Appendix: Basic Popcornish Lesson

to Microwave (v.) = to elicit, document, and analyze
popcorn (n.) = requirements
2.5 minutes (n.) = the up-front estimate or guesstimate
microwave (n.) = business analyst or business analysis team
500 watts (n.) = an attribute which measures the caliber of your team
distance between pops (n.) = time elapsed between receiving a new requirement or making a significant change to an existing requirement
2 seconds (n.) = the longest time your situation (you can replace with organization, team, management, etc.) will allow you or your team to stay idle while waiting for a new requirement or a significant change to an existing requirement

Your turn: How do you know when you're done or when you should be done?

Adrian

BA: If You Want to Succeed, You've Got to Read!

Adrian M. — Sun, 16 Nov 2014 22:15:00 GMT

To be an average analyst is fairly simple...

.... all you have to do is go to all the meetings, complete all the mandatory training courses, and listen to feedback from your manager.

But...

IF you want to be a GREAT analyst - if you want to truly be successful THEN that's not enough.

To truly succeed, you need an internal drive to continuously improve your skills and knowledge.

Systems Analysis, like any other profession, requires specialized skills and knowledge...

... and to be effective you need to develop in three key areas:

technical skills,
business domain knowledge, and
those very subjective soft skills.

Technical Skills are the foundation of your career. You surely would not trust a doctor who tells you that he's seen somebody else doing that surgery...

...but I brush against this scenario all the time when I interview systems analysts. When asked about his claimed expertise with "class diagrams", one such candidate told me that he once worked on a project where "they" used class diagrams. Who's they?

Technical know-how are those skills which are very specific to your profession. In our case it's use case modeling, object oriented analysis, Data Flow Diagrams, problem solving patterns, user stories, etc.

For starters, study and keep understand the methodology and best practices used in your place of employment. Then venture out on your own and learn a new skill. Pick up a book on agile stories - read an article on sequence diagrams - take a UML course.

Business Domain Knowledge, also known as vertical market knowledge, empowers you to easily grasp the requirements and to quickly spot problems within a given solution. A technically correct diagram is useless if the business information represented is wrong.

Mortgage Banking is our domain, specifically mortgage loan origination... This is a highly complex and challenging industry.

Up to the challenge?

Soft Skills are what distinguishes a good analyst from an effective analyst...

...you may have the best solution, but if you can't communicate it - the solution is worthless.

...you may have a great idea, but if you can't convince your manager to adopt it - it's useless.

...you may manage skilled analysts, but if you can't inspire them - your team will fall apart.

Soft skills are critical to Your success!

So... learn to negotiate... improve your communication skills... be quick to listen and slow to speak... increase your sphere of influence... inspire!

What do you think?

Adrian

Analyst ranks high in "A Comprehensive Ranking of 200 Different Jobs"

Adrian M. — Thu, 08 Jan 2009 20:21:00 GMT

JobsRated.com released the results of a study they did of 200 jobs and how they rank based on a number of factors such as:

Environment
Income
Outlook
Physical Demands
Stress

Systems Analysts was in the top 10 which looks like this:

Mathematician
Actuary
Statistician
Biologist
Software Engineer
Computer Systems Analyst
Historian
Sociologist
Industrial Designer
Accountant

So - just another piece of good news for the Business Analysts and Systems Analysts out there.

The business analyst cannot forget "The Why"!

Adrian M. — Thu, 08 Jan 2009 18:06:00 GMT

There are many tools and techniques available to the business analyst for a variety of tasks. One of my favorite one is the short table-style template for documenting a "Problem/Opportunity Statement" as follows:

The problem of
Affects
The impact of which is
A successful solution would

One big issue I often encounter is that participants in many requirements workshops, JAD sessions, and other such endeavors focus only on what a successful solution would look like. These sessions become "fun" sessions where screens are designed and features are envisioned, forgetting the Why!

By the way: both business SMEs and business analysts are guilty of this!

We can't be forgetting the Why! That's not an option.

Before the business analyst engages in any solution discussions he/she must ensure they clearly understand the problem statement and who/what/how the problem impacts.

What do you think?